Многие из вас знакомы с решением VMware App Volumes, которое предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Те из вас, кто его используют, время от времени, наверняка, сталкиваются с проблемой недостатка места на пользовательских томах Writable Volumes, которые забиваются неизвестно чем:
Напомним, что Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами. Соответственно, такие тома могут легко заполняться, и пользователи начинают жаловаться.
Aresh Sarkari написал полезный скрипт, который выявляет заполненные тома Writable Volumes в инфраструктуре App Volumes (меньше 3 ГБ свободного места), формирует CSV-файл с данными о них и посылает его по электронной почте администратору:
####################################################################
# Get List of Writable Volumes from AppVolumes Manager for free space less than 3 GB out of 30 GB
# Author - Aresh Sarkari (@askaresh)
# Version - V2.0
####################################################################
# Run at the start of each script to import the credentials
$Credentials = IMPORT-CLIXML "C:\Scripts\Secure-Creds\SCred_avmgr.xml"
$RESTAPIUser = $Credentials.UserName
$RESTAPIPassword = $Credentials.GetNetworkCredential().Password
$body = @{
username = “$RESTAPIUser"
password = “$RESTAPIPassword”
}
Invoke-RestMethod -SessionVariable DaLogin -Method Post -Uri "https://avolmanager.askaresh.com/cv_api/sessions” -Body $body
$output = Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "https://avolmanager.askaresh.com/cv_api/writables" -ContentType "application/json"
$output.datastores.writable_volumes | Select-Object owner_name, owner_upn,total_mb, free_mb, percent_available, status | Where-Object {$_.free_mb -lt 3072} | Export-Csv -NoTypeInformation -Append D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv
#send an email (provided the smtp server is reachable from where ever you are running this script)
$emailfrom = 'writablevolumes@askaresh.com'
$emailto = 'email1@askaresh.com', 'email2@askaresh.com' #Enter your SMTP Details
$emailsub = 'Wrtiable Volumes Size (free_mb) less than 3 GB out of 30 GB - 24 Hours'
$emailbody = 'Attached CSV File from App Volumes Manager. The attachment included the API response for all the Writable Volumes less than 3 GB of free space'
$emailattach = "D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv"
$emailsmtp = 'smtp.askaresh.com'
Send-MailMessage -From $emailfrom -To $emailto -Subject $emailsub -Body $emailbody -Attachments $emailattach -Priority High -DeliveryNotificationOption OnFailure -SmtpServer $emailsmtp
Последняя версия сценария PowerCLI для поиска заполненных томов доступна в репозитории на GitHub. Там же, кстати, есть сценарий для поиска Writable Volumes со статусом Disabled или Orphaned.
Не так давно мы писали о новых возможностях платформы для создания отказоустойчивых хранилищ виртуальных машин в инфраструктуре виртуализации VMware vSAN 7.0. Компания VMware недавно сделала доступными для загрузки все компоненты обновленной виртуальной инфраструктуры, но новые возможности получили далеко не все пользователи - их набор зависит от имеющейся лицензии.
Давайте посмотрим, какие возможности есть в каждом из четырех доступных изданий VMware vSAN 7.0:
Standard (гибридные хранилища HDD+SSD)
Advanced (All-Flash хранилища)
Enterprise (возможности для предприятий)
Enterprise Plus (гиперконвергентная инфраструктура)
Возможности vSAN 7
Политики хранилищ Storage Policy Based Management (SPBM)
На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.
Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.
Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):
Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.
Кластер отказоустойчивых хранилищ VMware vSAN состоит из нескольких хостов ESXi, на локальных хранилищах которых создаются дисковые группы, где размещаются данные виртуальных машин. В процессе создания, перемещения и удаления дисковых объектов ВМ распределение емкости на дисках может изменяться, иногда довольно существенно.
Все это приводит к дисбалансу кластера по дисковой емкости, что создает разную нагрузку на устройства, а это не очень хорошо:
В случае возникновения подобного дисбаланса в кластере VMware vSAN, в консоли vSphere Client на вкладке Monitor, в разделе vSAN Health появляется нотификация vSAN Disk Balance (выполняется эта проверка каждые 30 минут по умолчанию):
Чтобы устранить подобные ситуации, в кластере VMware vSAN есть механизм автоматической балансировки - Automatic Rebalance, который относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства.
По умолчанию пороговое значение составляет 30% (параметр Average Load Varinace - среднее значение разницы между минимальной и максимальной используемой емкостью на дисках в процентах). Это означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется автоматическая перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.
Также перебалансировка сама запустится, когда диск заполнен на более чем 80%. Надо помнить, что операция эта создает нагрузку на дисковые хранилища, поэтому надо учитывать, что у вас должен быть некоторый запас по производительности, чтобы автоматическая балансировка не съела полезные ресурсы.
В случае если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.
Эта опция называется ручной проактивной балансировкой кластера, она становится доступной когда разница в использовании дисковой емкости двух или более дисков начинает превышать 30%:
Если вы запускаете такую балансировку вручную, то продлится она по умолчанию 24 часа и затем сама остановится.
Надо понимать, что операция ребалансировки - это совершенно другая операция, нежели vSAN Resync. Она служит только целям сохранения равномерной нагрузки в кластере с точки зрения дисков.
Также есть возможность контроля операций ребалансировки с помощью интерфейса Ruby vSphere Console (RVC). Для этого вам нужно сменить пространство имен (namespace) на computers и выполнить следующую команду для кластера, чтобы посмотреть информацию о текущем балансе:
vsan.proactive_rebalance_info <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Результат выполнения команды будет, например, таким:
/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...
2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos
Proactive rebalance start: 2019-08-16 19:30:47 UTC
Proactive rebalance stop: 2019-08-17 19:30:54 UTC
Max usage difference triggering rebalancing: 30.00%
Average disk usage: 56.00%
Maximum disk usage: 63.00% (17.00% above minimum disk usage)
Imbalance index: 10.00%
No disk detected to be rebalanced
В этом случае ребалансировка не требуется. Если же вы, все-таки, хотите ее запустить, то делается это следующей командой:
vsan.proactive_rebalance -s <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Ну и вы можете изменить время, в течение которого будет идти ручная ребалансировка. Для этого задайте значение в секундах следующей командой (в данном примере - это 7 дней):
На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.
Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:
1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:
vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.
2. Службы Native File Services for vSAN
С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.
3. Развертывание приложений с использованием Enhanced Cloud Native Storage
Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.
4. Прочие улучшения
Тут появилось довольно много нового:
Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
Immediate repair operation after a vSAN Witness Host is replaced.
Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN.
Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.
Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.
На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.
StarWind HCA All-Flash
Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.
Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:
Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
Безопасное резервное копирование виртуальных машин
Проактивная поддержка вашей инфраструктуры специалистами StarWind
И многое, многое другое
Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:
После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.
Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.
Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:
Ядро продукта
Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
Максимальное число лог-файлов в ротации увеличено с 5 до 20.
Механизм синхронной репликации
Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.
Нотификации по электронной почте
Реализована поддержка SMTP-соединений через SSL/STARTTLS.
Добавлена возможность аутентификации на SMTP.
Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.
Компоненты VTL и Cloud Replication
Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
Исправлены ошибки в настройках CloudReplicator Settings.
Модуль StarWindX PowerShell
Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
Свойство "Valid" добавлено к HA channel.
Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).
Средство управления Management Console
Небольшие улучшения и исправления ошибок.
Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.
Таги: StarWind, Update, Storage, iSCSI, HCA, Hardware, SSD, HA, DR
Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.
К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:
Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:
Далее можно записать эту переменную в дефолтные параметры:
$PSDefaultParameterValues = @{
"*-pfa*:Array"=$flashArray;
}
Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).
Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:
После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:
Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.
Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.
Многие администраторы виртуальных инфраструктур в курсе про технологию NVMe (интерфейс Non-volatile Memory дисков SSD), которая была разработана для получения низких задержек и эффективного использования высокого параллелизма твердотельных накопителей. Такие устройства хоть и стоят дороже, но уже показывают свою эффективность за счет использования десятков тысяч очередей команд, что дает очень низкие задержки, требующиеся в таких сферах, как системы аналитики реального времени, онлайн-трейдинг и т.п.
К сожалению, протокол iSCSI (да и Fibre Channel тоже) разрабатывался тогда, когда инженеры еще не думали об архитектуре NVMe и высоком параллелизме, что привело к тому, что если использовать iSCSI для NVMe, использование таких хранилищ происходит неэффективно.
Главная причина - это одна очередь команд на одно устройство NVMe, которую может обслуживать iSCSI-протокол, весь смысл параллелизма теряется:
Вторая проблема - это то, что iSCSI использует процессор для диспетчеризации операций ввода-вывода, создавая дополнительную нагрузку на серверы, а также имеет некоторые сложности по перенаправлению потоков операций для нескольких контроллеров NVMe и устройств хранения на них.
Для этого и был придуман протокол NVMe over Fabrics (NVMe-oF), который не имеет таких ограничений, как iSCSI. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP.
Компания StarWind сделала свою реализацию данного протокола для продукта StarWind Virtual SAN, чтобы организовать максимально эффективное использование пространства хранения, организованного с помощью технологии NVMe. Об этом было объявлено еще осенью прошлого года. Он поддерживает 64 тысячи очередей, в каждой из которых, в свою очередь, может быть до 64 тысяч команд (в реальной жизни в одной очереди встречается до 512 команд).
Важный момент в реализации NVMe-oF - это применение технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы.
Также RDMA позволяет маппить несколько регионов памяти на одном NVMe-контроллере одновременно и организовать прямое общение типа точка-точка между инициаторами разных хостов (несколько Name Space IDs для одного региона) и этими регионами без нагрузки на CPU.
Такой подход, реализованный в продуктах StarWind, дает потрясающие результаты в плане производительности, о которых мы писали вот в этой статье. К этой статье можно еще добавить то, что реализация инициатора NVMe-oF на базе Windows-систем и таргета на базе Linux (который можно использовать в программно-аппаратных комплексах StarWind Hyperconverged Appliances, HCA) дала накладные издержки на реализацию всего 10 микросекунд по сравнению с цифрами, заявленными в даташитах производителя NVMe-устройств. Знающие люди поймут, насколько это мало.
Еще надо отметить, что бесплатный продукт StarWind NVMe-oF initiator - это единственная программная реализация инициатора NVMe-oF на сегодняшний день. В качестве таргета можно использовать решения Intel SPDK NVMe-oF Target и Linux NVMe-oF Target, что позволяет не зависеть жестко от решений StarWind.
Подробнее о StarWind NVMe-oF initiator можно узнать вот в этой статье. А загрузить его можно по этой ссылке.
На сайте проекта VMware Labs очередное обновление: вышло интересное средство для мониторинга кластеров VMware vSAN - мобильная утилита vSAN Live. С помощью данного приложения для iOS (9.0+) или Android (4.1+) можно организовать мониторинг инфраструктуры отказоустойчивых хранилищ vSAN, находясь за пределами инфраструктуры компании (например, в отпуске или командировке).
Полный список возможностей утилиты vSAN Live:
Дэшборд с обзором всех кластеров vSAN.
Полный набор выполняемых для vSAN хэлс чеков.
Просмотр структуры кластера, включая Fault domain и статусы хостов.
Простое переключение между серверами vCenter.
Просмотр конфигурации кластера, включая настройки vSAN и статус сервиса.
Полнофункциональный мониторинг производительности для виртуальных машин и кластера в целом, а также мониторинг емкости хранилищ кластера.
Самое полезное - это возможность выполнять health checks, что даст возможность понять, что и где сломалось в кластере vSAN:
Скачать приложение vSAN Live можно по этим ссылкам:
Для начала работы с приложением нужно скачать сертификат, расположенный на сервере vCenter по адресу:
https://<VC_FQDN>/afd/vecs/ca
Для установки сертификата на iOS:
Идем в Settings -> General -> Profiles -> CA -> Install
Далее: Settings -> About -> Certificate Trust Settings -> CA (enable)
Для установки сертификата на Android:
Открываем сертификат -> Даем ему имя -> Ставим "Credential Use: VPN and apps" -> жмем OK
Пока это всего лишь первая версия утилиты, в дальнейшем, будем надеяться, там появится еще больше интересных функций.
В последних числах августа компания StarWind Software, выпускающая продукты для организации хранилищ под виртуализацию, выпустила обновленную версию решения для создания iSCSI-хранилищ на платформах vSphere и Hyper-V - StarWind Virtual SAN V8 build 13182. Давайте посмотрим, что нового появилось в этом продукте...
Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.
Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:
Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.
Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:
Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:
Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.
Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:
В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.
На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?
Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).
В кластере vSAN это выглядит вот так:
Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.
Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.
С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):
Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).
Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:
Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.
С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:
Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.
Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.
На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:
Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.
Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.
Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.
Аппаратная спецификация кластера выглядела так:
Platform: Supermicro SuperServer 2029UZ-TR4+
CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
RAM: 96GB
Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
RAW capacity: 9TB
Usable capacity: 8.38TB
Working set capacity: 4.08TB
Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.
Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.
С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):
Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.
Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).
Далее результаты по IOPS были следующими:
90% random reads и 10% writes = 5,139,741 IOPS
70% random reads и 30% writes = 3,434,870 IOPS
Полная табличка выглядит так:
Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.
Для 100% sequential 2M block writes получили 100.29 GBps.
Полные результаты с учетом добавления двух дисков:
А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.
Полная таблица результатов со включенным кэшированием выглядит так:
Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).
Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.
Полные результаты этого теста:
Все остальное можно посмотреть на этой странице компании StarWind, которая ведет учет результатов. Зал славы сейчас выглядит так :)
Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.
Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.
Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).
Архитектура CNS реализована двумя компонентами:
Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.
Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.
Кстати, про оперирование CNS есть интересное видео от VMware:
Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.
До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.
Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.
Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.
Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.
Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.
Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.
Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.
Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:
Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.
Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.
На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.
С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.
С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.
Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.
Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:
Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
InfluxDB - собственно, сама база данных, хранящая метрики.
Grafana - это фреймворк, который используется для визуализации метрик из базы.
После развертывания администратору лишь нужно указать простые настройки и подключить коллектор к одному или нескольким целевым кластерам и стартовать сервис. После этого данные будут собираться на периодической основе и могут быть визуализованы в любой момент.
В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11 (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).
Скачать vSAN Performance Monitor можно по этой ссылке.
Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.
Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.
SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):
На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:
Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.
Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.
Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.
Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.
SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:
На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:
Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:
Так для Normal:
А так для High:
Если выберите вариант Custom, то дефолтно там будут такие значения:
Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.
Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:
После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:
Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).
Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.
Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:
Командлет может делать следующее:
Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
Ресканирует кластер, чтобы убедиться, что PE виден хостам.
Монтирует VVol в кластере.
Возвращает датастор хранилищу.
Пример 1 - имеется прямой доступ к массиву
Соединяемся с vCenter и создаем соединение с FlashArray:
Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:
Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:
Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:
Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака. В MIT предложили систему, которая в два раза уменьшит объем электричества, потребляемого «твердотельниками» в ЦОД. Рассказываем, как она устроена.
Проблема энергопотребления
Приблизительно через десять лет на вычислительные системы (в целом) будет приходиться40% потребляемой электроэнергии. За пятую часть этого объема будут «ответственны» центры обработки данных.
Системы хранения данных — один из основных «потребителей» электроэнергии в ЦОД. Чтобы сократить расходы на содержание СХД, операторы дата-центров заменяют жесткие диски на твердотельные накопители. Последние более производительны и энергоэффективны: известны случаи, когда SSD уменьшали объем потребляемого стойками СХД электричества на 60%.
Но ситуация все равно далека от идеальной. В машинном зале крупного дата-центра могут находиться сотни стоек с накопителями, и счета за электроэнергию остаются большими. Поэтому сегодня разрабатываются новые технологии, чтобы еще сильнее сократить энергопотребление SSD. Одну из таких технологий представили в MIT. Специалисты вуза спроектировали архитектуру системы хранения данных на базе твердотельных накопителей, которая снижает расходы операторов ЦОД на электричество в два раза. Ее назвали LightStore.
Как устроена система
LightStore представляет собой хранилище типа «ключ — значение» (KV-хранилище). Ключом считаются пользовательские запросы к СХД, а значением — сами данные. Систему разворачивают на специальном аппаратном узле в сети ЦОД. Его подключают напрямую, в обход серверов хранения данных (дополнительно потребляющих электроэнергию).
Узел построен на базе энергоэффективного CPU, а также NAND- и DRAM-памяти. Управляет им контроллер и специализированное ПО. Первый компонент отвечает за обмен данными с массивами NAND, а второй — за хранение ключей и их обработку. В основе программной архитектуры LightStore лежат так называемые LSM-деревья — структуры данных, используемые во всех современных СУБД.
Кластер LightStore масштабируется линейно путем подключения дополнительных узлов к сети. Для этих целей применяются специальные адаптеры. Они формализуют пользовательские запросы к СХД и трансформируют их в понятные для нее команды. Обработка запросов производится с использованием согласованного хеширования — при добавлении новой пары ключ-значение, хеш рассчитывается только для нее, а не для всех пар. Аналогичный подход применяют системы Redis и Swift.
В общем случае архитектуру LightStore и схему ее подключений в ЦОД можно представить вот так:
По словам разработчиков, пропускная способность LightStore при работе в 10GbE-сети дата-центра превышает 600 Мбит/с. При этом один ее узел потребляет на 10 Вт меньше, чем узел «классических» SSD-систем — для них этот показатель равен 20 Вт. Также оборудование занимает в два раза меньше места, отчасти из-за того, что LightStore не требуются серверы хранения.
Сейчас инженеры из MIT занимаются исправлением недостатков LightStore и расширением функциональности системы. Например, ее «учат» работать с атомарными запросами и запросами по диапазону. Также в планах разработчиков добавить поддержку SQL-запросов. Авторы убеждены, что в будущем LightStore может стать отраслевым стандартом для SSD-хранилищ в центрах обработки данных.
Аналоги решения
В прошлом году компания Marvell, которая занимается разработкой СХД, анонсировала SSD-контроллеры с интеллектуальными функциями. Они построены на базе систем ИИ, которые оптимизируют энергопотребление SSD в ЦОД. Ожидается, что решение найдет применение в машинных залах организаций, занимающихся аналитикой больших данных.
Еще один пример — накопитель WD Blue SSD с повышенной производительностью и энергоэффективностью. Устройство использует спецификацию NVMe для подключения дисков к шине PCI Express. Такой подход позволил повысить эффективность накопителя при работе с большим числом параллельных запросов. Устройство имеет скорость чтения в 545 МБ/с и скорость записи в 525 МБ/с. NVMe может стать стандартом ИТ-индустрии для SSD-интерфейсов. Производителям аппаратного обеспечения больше не придется расходовать ресурсы на разработку уникальных драйверов и разъемов.
В будущем можно ожидать появления большего числа решений, повышающих энергоэффективность СХД, подобных системам из MIT, Marvell и WD.
Вопрос этот важен, так как многие пользуются лимитами для виртуальных машин на уровне хранилищ vSAN, но не хотят, чтобы в случае сбоя ресинхронизация кластера или перемещение машин происходили с ограничениями, которые могут увеличить время восстановления в разы.
Ответ тут прост - нет, не влияет. Лимиты устанавливаются на уровне гостевой системы для VMDK-дисков виртуальных машин и сопутствующих объектов (например, снапшоты, своп и т.п.), поэтому операции, которые проводятся извне со стороны платформы, в этом не участвуют.
Таким образом, лимиты для виртуальных машин можно ставить без ограничений и не заботиться о том, что это повлияет на время восстановление кластера и отдельных ВМ в случае сбоя. Операции SVMotion также затронуты не будут.
Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.
Основная фича утилиты - возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как размер IO и паттерн нагрузки, пакетирование (объем исходящих операций ввода-вывода), временные промежутки между пакетами, микс трафика чтения/записи, буфферизованные или прямые операции ввода-вывода и многое другое.
IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.
IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:
1. Выравнивание доступа к памяти по 4 КБ (страница памяти).
2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).
Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.
Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.
Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.
Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.
Что нового появилось в HCIBench 2.1:
Интерфейс переключили на темную тему.
Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
Добавлена возможность обновления процесса подготовки VMDK.
Добавлена проверка портов базы данных Graphite в процесс превалидации.
Пароли vCenter и хостов ESXi затемняются при сохранении
Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.
При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.
Некоторые дисковые объекты машин вы можете исключить из растянутого кластера и не реплицировать их между площадками. Такая настройка в HTML5-клиенте выглядит следующим образом:
В старом интерфейсе vSphere Web Client это настраивается вот тут:
Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.
Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.
Если такая машина работает не в растянутом кластере vSAN, то в случае, если произойдет разрыв между площадками - часть дисков в гостевой системе станет недоступна, что неприемлемо для приложений и ОС.
Поэтому всегда убеждайтесь, что машина и ее дисковые объекты всегда находятся на одном сайте, для этого задавайте их локацию явно:
Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:
The ramdisk 'tmp' is full
Выглядит это чаще всего вот так:
Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.
Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:
В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:
Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:
Вчера мы писали об ограничениях технологии Persistent Memory в vSphere 6.7, которая еще только изучается пользователями виртуальных инфраструктур на предмет эксплуатации в производственной среде. Преимущество такой памяти - это, конечно же, ее быстродействие и энергонезависимость, что позволяет применять ее в высокопроизводительных вычислениях (High Performance Computing, HPC).
Ну а пока все это изучается, сейчас самое время для проведения всякого рода тестирований.
NVDIMM-N от компаний DELL EMC и HPE. NVDIMM-N - это такой тип устройств DIMM, который содержит модули DRAM и NANDflash на самом DIMM. Данные перемещаются между двумя этими модулями при запуске или выключении машины, а также во время внезапной потери питания (на этот случай есть батарейки на плате). На текущий момент есть модули 16 GB NVDIMM-Ns.
Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они измеряются наносекундами. Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM.
Для тестирования производительности такой памяти были использованы следующие конфигурации тестовой среды:
При тестировании производительности ввода-вывода были сделаны следующие заключения:
Накладные расходы на поддержку PMEM составляют менее 4%.
Конфигурация vPMEM-aware (когда приложение знает о vPMEM устройстве) может дать до 3x и более прироста пропускной способности в смешанном потоке чтения-записи в сравнении с традиционными устройствами vNVMe SSD (они использовались в качестве базового уровня).
Задержки (latency) на уровне приложений для конфигураций vPMEM составили менее 1 микросекунды.
Также тестировалась производительность баз данных Oracle, и там были сделаны такие выводы:
Улучшение на 28% в производительности приложения (количество транзакций HammerDB в минуту) с vPMEM по сравнению с vNVME SSD.
Увеличение 1.25x DB reads, 2.24x DB writes и до 16.6x в числе записей в DB log.
До 66 раз больше уменьшение задержек при выполнении операций в Oracle DB.
В MySQL тоже весьма существенное улучшение производительности:
Для PMEM-aware приложений тоже хорошие результаты:
Ну а остальные детали процесса проведения тестирования производительности устройств PMEM вы найдете в документе VMware.
Компания StarWind Software известна пользователям как производитель лучшего в отрасли программного решения Virtual SAN для создания отказоустойчивых хранилищ на базе хост-серверов виртуализации VMware vSphere и Microsoft Hyper-V. StarWind иногда выпускает бесплатные утилиты для администраторов виртуальных инфраструктур, и сегодня мы поговорим об очередной новинке - StarWind iSCSI Accelerator...
Недавно мы писали об утилите для тестирования производительности хранилищ HCIBench 2.0, которая помогает администраторам VMware vSphere валидировать конфигурацию кластера с точки зрения соответствия требованиям к производительности подсистемы хранения для приложений датацентра.
HCIBench используется для проведения синтетических тестов кластера хранилищ, когда нагрузка распределяется по нескольким виртуальным машинам на разных хостах ESXi. Генерация операций ввода-вывода происходит одновременно с разных ВМ согласно заранее определенному шаблону нагрузки.
А зачем вообще проводить тестирование кластера vSAN? Тут, как правило, есть следующие причины:
Понимание возможностей инфраструктуры хранения и возможность убедиться в том, что в ней нет аномалий.
Валидировать дизайн кластера vSAN с точки зрения приемо-сдаточных испытаний (User Acceptance Testing, UAT).
Получить референсные значения, с которыми можно будет сверяться при внесении существенных изменений в архитектуру vSAN.
Проведение тестов перед внедрением (PoC-проекты).
Установление базового уровня пользовательских ожиданий после развертывания приложений.
По итогу тестирования производительности хранилищ vSAN вы должны получить ответы на следующие вопросы:
Какого наибольшего числа операций ввода-вывода в секунду (IOPS) можно добиться?
Какая ожидаемая задержка выполнения операций (latency) при требуемом числе IOPS для рабочей нагрузки?
Какая максимальная пропускная способность операций чтения-записи (throughput)?
То есть результаты тестирования держатся на трех китах - IOPS, latency и throughput.
При проведении тестов нужно отключать все тормозящие технологии, такие как дедупликация и компрессия данных, а также шифрование на уровне кластера vSAN.
IOPS
Число выдаваемых IOPS зависит как от используемого оборудования для хостов и сетевых компонентов, так и от архитектуры системы. Актуальное число IOPS также зависит от уровня RAID в кластере vSAN, числа сетевых соединений между хостами, их загрузки и прочих факторов.
Обычно начинают тестирование с нескольких тредов на дисковый объект, а затем постепенно увеличивают это количество тредов, пока число выдаваемых IOPS не прекратит расти. При проведении тестирования число IOPS коррелирует с Latency, так как при увеличении одной операции ввода-вывода (размер блока операции) уменьшается число выдаваемых IOPS, а также увеличивается latency.
Latency
Обычно задержку измеряют в миллисекундах со стороны приложений, которые выполняют определенные операции. При этом, зачастую, нет каких-то референсных значений, их приходится выяснять экспериментальным путем (насколько это устраивает пользователей).
К увеличению задержек при выполнении операций приводят увеличение блока ввода-вывода, соотношение операций чтения и записи, одновременность исполнения операций ввода-вывода со стороны нескольких виртуальных машин и т.п.
Throughput
Пропускная способность важна при выполнении больших операций ввода-вывода, а также при различных паттернах чтения записи (последовательный/случайный). Чем больше размер I/O, тем очевидно больше пропускная способность. С точки зрения объема передаваемых данных одна операция I/O размером 256К равна 64 операциям ввода-вывода по 4К, но вот с точки зрения throughput это будут совершенно разные значения, так как займут разное время.
Методология тестирования хорошо описана в документации по HCIBench, а также вот в этой статье на русском языке. Работа с утилитой начинается по ссылке https://<HCIBench IP address>:8443.
Перед началом тестирования можно задать параметры среды - число виртуальных машин для кластера, количество их виртуальных дисков и их размер. Для ленивых есть параметр Easy Run, который позволит автоматически подобрать эту конфигурацию, исходя из размера кластера vSAN и параметров хостов ESXi:
Очень важно при тестировании также задать правильный профиль рабочей нагрузки (4 варианта на картинке выше).
После выполнения теста Easy Run вы получите выходной файл с результатами вроде vdb-8vmdk-100ws-4k-70rdpct-100randompct-4threads-xxxxxxxxxx-res.txt. Из имени файла можно понять использованную тестовую конфигурацию (она также будет в самом файле):
Также в папке с результатами тестирования будет подпапка с отдельными файлами, где хранятся результаты самих тестов:
Если открыть один их этих файлов, мы увидим детальные параметры производительности различных компонентов среды vSAN:
Полученные параметры можно считать базовым уровнем для тестирования производительности кластера. Теперь нужно увеличивать параллелизм, то есть число тредов Outstanding I/O (OIO), для выжимки оптимальной производительности. Увеличение этого параметра будет увеличивать число IOPS, а также, как следствие, будет расти Latency. Так вы сможете понять, как инфраструктура хранения ведет себя в динамике, реагируя на изменение профиля нагрузки.
Чтобы изменить параметр OIO, нужно отключить Easy Run и в профиле рабочей нагрузки нажать Add:
Также для измерения пропускной способности вы можете поэкспериментировать с размером операции ввода-вывода. Современные ОС поддерживают размер I/O в диапазоне 32K - 1 MB, но для тестирования лучше использовать I/O в диапазоне 32K – 256K.
Еще какие моменты надо учитывать при тестировании:
Синтетическое тестирование не учитывает, что профиль рабочей нагрузки в кластере в реальной жизни постоянно изменяется точки зрения соотношения операций чтения и записи и их рандомизации в потоке ввода-вывода. Используемая модель - всего лишь аппроксимация.
Тесты ориентированы на отслеживание характеристик хранилищ, а не загрузки CPU и памяти хостов ESXi.
Мы много пишем о решении для организации отказоустойчивых хранилищ на базе хостов ESXi - платформе VMware vSAN. Сегодня мы расскажем о дисковых группах на основе вот этого поста на блогах VMware.
Архитектура vSAN включает в себя два яруса - кэш (cache tier) и пространство постоянного хранения (capacity tier). Такая структура дает возможность достичь максимальной производительности по вводу-выводу, которая абсолютно необходима в кластере хранилищ на базе хостов.
Чтобы управлять отношениями устройств кэша и дисков хранения, решение vSAN использует дисковые группы:
У дисковых групп есть следующие особенности:
Каждый хост, который дает емкость кластеру vSAN, должен содержать как минимум одну дисковую группу.
Дисковая группа содержит как минимум одно устройство для кэша и от 1 до 7 устройств хранения.
Каждый хост ESXi в кластере vSAN может иметь до 5 групп, а каждая группа - до 7 устройств хранения. То есть на хосте может быть до 35 устройств хранения, чего вполне достаточно для подавляющего большинства вариантов использования.
Неважно, используете ли вы гибридную конфигурацию (SSD и HDD диски) или All-Flash, устройство кэширования должно быть Flash-устройством.
В гибридной конфигурации устройства кэша на 70% используются как кэш на чтение (read cache) и на 30% как кэш на запись (write buffer).
В конфигурации All-Flash 100% устройства кэша выделено под write buffer.
Write buffer и capacity tier
В принципе, всем понятно, что гибридная конфигурация хостов ESXi в кластере vSAN более дешевая (HDD стоит меньше SSD), но менее производительная, чем All-Flash. Но когда-то наступит время, и все будет All-Flash (в них, кстати, еще и нет нужды организовывать кэш на чтение, так как все читается с SSD с той же скоростью). Поэтому и выделяется 100% под write buffer.
При этом если операция чтения в All-Flash хосте находит блок в кэше - то он читается именно оттуда, чтобы не искать его в capacity tier. Максимальный размер write buffer на одной дисковой группе хоста ESXi - 600 ГБ. При этом если сам диск более 600 ГБ, то его емкость будет использоваться с пользой (см. комментарий к этой статье).
Для гибридных конфигураций 70% емкости кэша выделяется под кэш на чтение, чтобы быстро получать данные с производительных SSD-устройств, при этом vSAN старается поддерживать коэффициент попадания в кэш на чтение (cache hit rate) на уровне 90%.
Write buffer (он же write-back buffer) подтверждает запись на устройство хранения еще до актуальной записи блоков на сapacity tier. Такой подход дает время и возможность организовать операции записи наиболее эффективно и записать их на сapacity tier уже пачкой и более эффективно. Это дает существенный выигрыш в производительности.
SSD-устройства бывают разных классов, в зависимости от их выносливости (среднее число операций записи до его отказа). Все понятно, что для кэширования нужно использовать устройства высоких классов (они дорогие), так как перезапись там идет постоянно, а для хранения - можно использовать недорогие SSD-диски.
Вот сравнительная таблица этих классов (колонка TBW - это terabytes written, то есть перезапись скольких ТБ они переживут):
vSAN содержит в себе несколько алгоритмов, которые учитывают, как часто write buffer сбрасывает данные на сapacity tier. Они учитывают такие параметры, как емкость устройств, их близость к кэшу по времени записи, число входящих операций ввода-вывода, очереди, использование дискового устройства и прочее.
Организация дисковых групп
При планировании хостов ESXi в кластере vSAN можно делать на нем одну или более дисковых групп. Несколько дисковых групп использовать предпочтительнее. Давайте рассмотрим пример:
Одна дисковая группа с одним кэшем и 6 устройств хранения в ней.
Две дисковых группы с двумя устройствами кэша, в каждой по 3 устройства хранения.
Если в первом случае ломается SSD-устройство кэша, то в офлайн уходит вся дисковая группа из 6 дисков, а во втором случае поломка одного девайса приведет к выходу из строя только трех дисков.
Надо понимать, что этот кейс не имеет прямого отношения к доступности данных виртуальных машин, которая определяется политикой FTT (Failures to tolerate) - о ней мы подробно рассказывали тут, а также политиками хранилищ SPBM. Между тем, размер домена отказа (failure domain) во втором случае меньше, а значит и создает меньше рисков для функционирования кластера. Также восстановление и ребилд данных на три диска займет в два раза меньше времени, чем на шесть.
Кстати, некоторые думают, что в случае отказа дисковой группы, кластер vSAN будет ждать 60 минут (настройка Object Repair Timer) до начала восстановления данных на другие диски согласно политике FTT (ребилд), но это неверно. Если вы посмотрите наш пост тут, то поймете, что 60 минут vSAN ждет в случае APD (All Paths Down - например, временное выпадение из сети), а вот в случае PDL (Physical Device Loss) восстановление данных на другие дисковые группы начнется немедленно.
С точки зрения производительности, иметь 2 дисковые группы также выгоднее, чем одну, особенно если разнести их по разным контроллерам хранилищ (storage controllers). Ну и это более гибко в обслуживании и размещении данных на физических устройствах (например, замена диска во втором примере пройдет быстрее).
Работа операций ввода-вывода (I/O)
Как уже было сказано, в гибридной конфигурации есть кэши на чтение и на запись, а в All-Flash - только на запись:
При этом хост ESXi работает так, чтобы операции чтения с дисков попадали в кэш на чтение в 90% случаев. Остальные 10% операций чтения затрагивают HDD-диски и вытаскивают блоки с них. Но и тут применяются оптимизации - например, одновременно с вытаскиванием запрошенного блока, vSAN подтягивает в кэш еще 1 МБ данных вокруг него, чтобы последовательное чтение проходило быстрее.
Для All-Flash конфигурации кэш на чтение не нужен - все данные вытаскиваются с примерно одинаковой скоростью, зато все 100% кэша используются под write buffer, что дает преимущество в скорости обработки большого входящего потока операций ввода-вывода.
Ну и напоследок отметим, что vSAN при записи на флэш-диски распределяет операции записи равномерно между ячейками независимо от размера диска. Это позволяет диску изнашиваться равномерно и иметь бОльшую наработку на отказ.
Компания StarWind хорошо всем вам известна как лидер отрасли в сфере производства программных и программно-аппаратных хранилищ под инфраструктуру виртуализации. В частности, одно из самых популярных решений StarWind Virtual SAN позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на базе всего двух серверов.
Эти серверы могут исполнять как вычислительную нагрузку для ВМ, так и предоставлять ресурсы хранения. Когда все аспекты инфраструктуры объединяются в единую систему управления, такая инфраструктура называется гиперконвергентной (Hyperconverged Infrastructure, HCI).
Недавно компания StarWind анонсировала HCI-решение Command Center, которое позволит из единого интерфейса осуществлять мониторинг виртуальной среды на базе хранилищ Virtual SAN, а также управлять ею.
Command Center - это веб-интерфейс, построенный на базе технологии HTML5, который дает средства для управления виртуальными машинами и хост-серверами виртуализации, где для каждой из сущностей доступно до 100 различных параметров настройки. Единая панель управления инфраструктуры HCI позволяет выполнять ежедневные операции до 5 раз быстрее по сравнению с использованием нескольких консолей.
С помощью Command Center можно будет не только управлять сущностями виртуальной инфраструктуры, но и контролировать такие процессы, как оркестрация операций, резервное копирование Veeam Backup & Replication и многое другое.
Только 5% функционала Command Center приходится на решение Virtual SAN, остальное - это управление гипервизорами, резервным копированием, инфраструктурой публичных облаков и прочими аспектами. Кстати, Command Center будет поддерживать различные гипервизоры - VMware vSphere, Microsoft Hyper-V, Red Hat KVM и, возможно, другие платформы.
С продуктом можно будет опционально докупить StarWind ProActive Support - она позволит собирать телеметрию с компонентов Command Center и на основе аналитики на стороне StarWind (ML/DL) выявлять причины возникающих проблем.
RSS
